Cronologia lineare tramite fast-forwarding è possibile solo quando la storia dei rami è una linea retta di discendenti. Nel momento in cui il ramo principale e il ramo della funzionalità si separano, il semplice 'spostamento del puntatore' di un merge con fast-forward diventa matematicamente impossibile.

1. La differenza tangibile

I merge con fast-forward non sono riflessi nella cronologia del progetto. Ciò significa che l'esistenza unica del ramo viene effettivamente cancellata all'integrazione. Al contrario, i merge a tre vie preservano il racconto del lavoro parallelo.

2. Il principio dell'archivista

Il ramo master agisce come archivista per tutto il nostro progetto. Può registrare solo ciò che gli permettiamo di vedere; quando i percorsi si dividono, siamo costretti a creare un nuovo 'evento'—un commit di merge—per colmare il divario e conciliare due realtà diverse che si sono evolute simultaneamente.

3. Rilevamento della divergenza

Usando git log --oneline, gli sviluppatori possono visualizzare dove i percorsi si dividono. Se 'master' si è spostato in avanti dal momento in cui hai creato il ramo, Git non può spostare il puntatore in avanti senza perdere il nuovo lavoro su master.